Tracking Certificate Misissuance in the Wild

Certificate Authorities (CAs) regularly make mechanical errors when issuing certificates. To quantify these errors, we introduce ZLint, a certificate linter that codifies the policies set forth by the CA/Browser Forum Baseline Requirements and RFC 5280 that can be tested in isolation. We run ZLint on browser-trusted certificates in Censys and systematically analyze how well CAs construct certificates. We find that the number errors has drastically reduced since 2012. In 2017, only 0.02% of certificates have errors. However, this is largely due to a handful of large authorities that consistently issue correct certificates. There remains a long tail of small authorities that regularly issue non-conformant certificates. We further find that issuing certificates with errors is correlated with other types of mismanagement and for large authorities, browser action. Drawing on our analysis, we conclude with a discussion on how the community can best use lint data to identify authorities with worrisome organizational practices and ensure long-term health of the Web PKI. I . I N T R O D U C T I O N HTTPS depends on a supporting public key infrastructure (PKI) composed of hundreds of certificate authorities (CAs) that verify the identities of websites and issue digital certificates. To ensure compatibility between between browsers and HTTPS-enabled websites, standards bodies like the IETF and CA/Browser Forum have developed policies that govern the digital certificates that CAs provide. Unfortunately, there is a long history of certificate authorities failing to adhere to accepted standards, due to both implementation errors and indifference. In this paper, we systematically analyze the errors that authorities make when constructing certificates and consider whether these errors can be used to predict more serious problems. We begin by dissecting the policies set forth by RFC 5280 [14] and CA/Browser Forum Baseline Requirements [9]. We find that many aspects of certificate construction can be checked in isolation, and we codify these requirements in a set of 220 lints. We introduce and release ZLint, a Go-based linting framework that implements these checks and provides structured data on certificate construction and standards adherence. To quantify misissuance (i.e., certificates with errors) in the Web PKI, we run ZLint on the 240 million browser-trusted certificates in Censys [17]. We find that misissuance is low in aggregate. Only 0.02% of certificates violate one of the two standards in 2017; 3.3% do not adhere to community best practices. This is a significant improvement from 2012 when more than 12% of certificates contained errors and nearly one third violated community recommendations. However, while the global misissuance rate is low, this is predominantly due to a handful of large authorities that consistently issue certificates without error. The three largest CAs by organization—Let’s Encrypt, Comodo, and cPanel—signed 80% of the certificates in our dataset and have near-zero misissuance rates. Let’s Encrypt, the largest CA by number of certificates issued, has a particularly stellar incident rate. Of the 37 million certificates the CA has signed, only 13 contain errors. None have warnings. The bulk of misissuance is due to two classes of authorities. The first class is mid-sized authorities that make a variety of errors in a small percentage of their certificates. The second class is a long tail of small authorities that make the same errors in every issued certificate. Nearly half of the organizations in our dataset misissue more than 10% of certificates, and eighteen have made errors in every certificate. More than half of the errors and warnings in ZLint are triggered at least once. Most often, authorities fail to fully populate the Subject Alternative Names extension, encode the wrong type of data in the extension, or include invalid DNS names. Beyond individual certificates, we find that many organizations struggle to properly maintain OCSP/CRL responders. During our three week test period, the OCSP responders for 73 organizations (10%) failed every health check. Next, in order to determine whether Lint data can be used to predict more serious issues, we investigate the correlation between the organizations that issue certificates containing errors, OCSP/CRL endpoint uptime, and browser removal. We find that there is weak correlation between the organizations that issue certificates with errors and OCSP availability. For authorities that have issued more than 100K certificates, there is moderate to strong correlation between ZLint-identified misissuance and browser removal. Surprisingly, while there is discussion about large CAs with high error profiles, there is no correlation between the small authorities making errors and discussion in the community (e.g., in the Mozilla Developer Security Policy mailing list). Our results indicate that large authorities are making progress in correctly issuing certificates. However, there remains a long tail of small authorities that fail to follow community standards and misissue most certificates. Most of these small authorities are not being actively discussed. We hope that by shedding light on these practices, we motivate the community to investigate struggling authorities and prompt discussion on whether lint data can be systemically used to help prevent Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author’s employer if the paper was prepared within the scope of employment. future PKI incidents. Finally, by releasing ZLint, we hope to help certificate authorities avoid making errors in the future. I I . B A C K G R O U N D HTTPS—and TLS more broadly—depend on a supporting public key infrastructure (PKI). The Web PKI that supports HTTPS on the public Internet consists of hundreds of certificate authorities (CAs)—organizations that user agents like browsers trust to verify the identities of websites and provide digital certificates. More than 400 organizations, ranging from commercial CAs to academic institutions, controlled browser-trusted signing certificates in 2013 [19]. The Web PKI was historically opaque as certificates and their issuers were often unknown until found in the wild. However, repeated compromise and anecdotes of negligence led to increased scrutiny and community initiatives to publicly log known certificates, analyze CA behavior, establish technical standards, and distrust abusive organizations. Our work builds on several of these initiatives: Certificate Transparency Logs. Certificate Transparency (CT) is a Google-initiated effort to maintain public, cryptographicallyverifiable ledgers of all browser-trusted certificates (logs) [27]. Originally started in 2013, CT logs initially contained certificates found primarily through Google web crawls and Internetwide scanning. Since then, several large authorities (e.g., Let’s Encrypt and Symantec) have started logging certificates at the time of issuance [22], [45]. In 2017, Google Chrome announced plans to require CT logging for browser trust [41]; other browsers are expected to follow [33]. As a result, public certificate transparency servers have become a de facto data source for monitoring the PKI. Internet-Wide Scanning. In 2010, research groups began to use Internet-wide scanning to identify trusted certificate authorities and to publish data sets of known certificates [19]– [21], [26]. These scans helped to identify the widespread delegation of signing credentials and uncover abuse. While much of the community now relies on CT servers for data, Vandersloot et al. recently found that the combination of CT and Internet-wide scanning provides the most comprehensive perspective of the PKI [47]. For our study, we use Censys [17], which aggregates certificates from publicly known CT servers and IPv4 scans of common protocols. CA/Browser Forum. The CA/Browser Forum is a voluntary consortium of certificate authorities, browsers, and other PKI participants [9]. The forum maintains several binding technical guidelines. In June 2007, the CA/Browser Forum published their first standard, Guidelines For The Issuance And Management Of Extended Validation (EV) Certificates [10], which outlines the expectations associated with issuing EV certificates. In 2011, the Forum established a second standard, Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates [9], colloquially referred to as the Baseline Requirements or BRs. The CA/B Forum Baseline Requirements are binding for all member organizations and apply to certificates issued for web authentication. This enforcement is often performed by participating web browsers. Common CA Database (CCADB). The Common CA Database (CCADB) is a Mozilla-led effort to establish a public database of trusted certificate authorities [32]. As part of its root store policy, Mozilla requires that roots submit unconstrained intermediates to CCADB [31]. We use CCADB to help identify the owners of signing certificates. Mozilla Developer Security Policy Mailing List. The Mozilla Developer Security Policy (MDSP) mailing list [1] is the primary public forum for discussing the Mozilla Root Program. It has become a de facto location for community members to disclose PKI issues and for browsers to solicit feedback from both CAs and the broader community. We use MDSP to identify which certificate authorities are being actively discussed. Increased transparency has led browsers to distrust several authorities over the past three years. Chrome and Firefox distrusted WoSign and StartCom after they were found issuing backdated SHA-1 certificates [34], [49]. PROCERT was distrusted in 2017 after multiple incidents of misissuance [29]. Chrome announced plans in 2017 to gradually distrust Symantec roots after a long history of problems [30], [35].